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(57) Abstract 

This software tool 
accessing methodology 
defines a powerful approach 
to interacting with smart 
card readers and smart cards. 
This software tool embodies 
the central software engine 
(Interface component), 
a series of configuration 
files, and modular plug-ins 
that provide methods 
for formatting cards and 
compatibility with evolving 
standards. This software tool 
enables effective building 
of smart card solutions 
without concern for the 
tedious detail of smart card 
vendor specifications and the 
unique interface challenges 
that exist with smart card 
readers. Instead of having to 
hardcode instructions within 
a smart card application, card 
and reader information is 
accessed by the interface 
component using the data 
stored in configuration files 
to therefore create flexibility 

and growth potential. The configuration files include information that tells how a software engine can communicate with an information 
system, a reader, and a card. This software tool is a turn-key solution when compared to existing very rudimentary smart card application 
development tools that require considerable smart card expertise and are limited to a single card or reader type. 
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METHOD AND APPARATUS FOR FORMATTING 
SMART CARDS AND CARD READERS 

Field of the Invention 

The present invention relates to a card methodology 
and architecture for configuring a software engine used 
for creating new smart card applications within a 
programming environment, and more specifically relates 
5 to a software tool and methodology that provides 
flexibility in formatting and interfacing smart cards, 
card readers and information systems in an object- 
oriented application development environment. 
Background of the Invention 

10 In the past, many different smart card readers 

existed and many different smart cards were available. 
However, while some similarities existed among the 
various card readers and smart cards, every vender had 
unique features and capabilities that differentiated 

15 their products. This presented a steep learning curve 
for application developers who had to learn the 
intricate details regarding how a particular card and 
card reader functioned. In addition, once an 

application had been designed, transition across 

20 hardware products was very difficult without significant 
code rewrites. The software tools provided by hardware 
vendors were either weak or non-existent and thus 
created the following problems. 

For every different reader or card, there existed 

25 a unique set of commands. Example commands included: 
create file, create directory, present secret code, load 
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secret code, reset reader, eject card, etc. Each 
command had an associated hexadecimal instruction. 
Addition or variation of commands or instructions 
created big problems since the instructions were 
5 hardcoded within the software engine. For example, a 
card could have the following commands: create file, 
write file, present code, and load code. However, if a 
new command were to be added such as "update code" , the 
entire software engine would have had to have been 

10 rewritten. This would have been cumbersome, 

inconvenient, and time-consuming. 

With regard to readers, readers also differed in 
the way that they communicated with the cards, drew 
power (battery, host, external) , processed commands, and 

15 reported status and errors, for example. With regard to 
the cards, the cards were also very diverse (magnetic 
stripe cards, memory chip cards such as simple flash 
memory cards, card operating systems known as COS chip 
cards with programmable operating systems, and others) . 

20 Even within the COS family of cards, there were 
different support elements for directory structures, 
file allocation and access, encryption, secret codes, 
status and error messages, etc. 

In a system utilizing different smart cards and 

25 smart card readers, such a system was quite cumbersome, 
mostly because of the specialized smart card software 
that was provided by the hardware manufactures. Many of 
the tools for creating specialized smart cards to comply 
with a user's desired specifications were not high-level 

30 tools and were not easy to use. The tools did not 
create any common way to work with different smart cards 
and readers, and there was no existing development tool 
that permitted development of an application for 
different readers and cards. 

3 5 Summary of the Invention 

A first object of the present application is to 
overcome the aforementioned drawbacks and to create a 
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smart card software tool useable in an interfacing 
architecture that allows a user to similarly interface 
with smart cards and/or card readers despite the source 
and compatibility standard of each card or reader. 
5 Another object of the present application is to 

provide a self -configuring software engine usable for 
communicating with cards and card readers having 
different formats and for creating and using files, 
directories or secret codes, for example. 

10 A still further object of the present application 

is to provide a tool for modifying smart card or card 
reader commands without the need to re-write an entire 
software engine. 

An even further object of the present application 

15 is to create a tool which provides flexibility by 
allowing the reformatting of a smart card and/or card 
reader with new information. 

These and other objects of the present application 
are fulfilled by providing a method for communicating 

20 with a card and a card reader, comprising the steps of: 
prestoring a plurality of files for configuring a 
software tool for communicating with the card as card 
configuration files; prestoring a plurality of files for 
configuring a software tool for communicating with the 

25 card reader as^ reader configuration files; selecting a 
card configuration file; selecting a reader 
configuration file; storing the selected card 
configuration file and reader configuration file; and 
configuring the software tool for communicating with the 

30 card and card reader based upon the respective stored 
selected card and card reader configuration files. 

These and other objects of the present application 
are further fulfilled by providing a method for 
communicating with a card, comprising the steps of: 

35 prestoring a plurality of files for configuring a 
software tool for communicating with a card; selecting 
one of the prestored files; storing the selected file; 
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and configuring the software tool for communicating 
with the card based upon the stored selected file. 

These and other objects of the present application 
are still further fulfilled by providing a method for 
5 communicating with a card reader, comprising the steps 
of: prestoring a plurality of files for configuring a 
software tool for communicating with a card reader; 
selecting one of the prestored files; storing the 
selected file; and configuring the software tool for 

10 communicating with the card reader based upon the stored 
selected file* 

These and other objects of the present application 
are even further fulfilled by providing an apparatus for 
formatting a card, comprising: a first memory for 

15 prestoring a plurality of card configuration files for 
configuring a software tool for formatting the card; a 
selection function for selecting one of the prestored 
card configuration files based upon card type; a dynamic 
memory for storing the card configuration file selected 

20 based upon card type, wherein the software tool is 
configured based upon the stored card configuration 
file, the selection function further selects at least 
one command for formatting the card, and the selected at 
least one command is stored in memory on the card; and 

25 processing function for formatting the card based upon 
the at least one selected stored command. 

These and other objects of the present application 
are still yet further fulfilled by providing an 
apparatus for formatting a card reader, comprising: a 

30 first memory for prestoring a plurality of card reader 
configuration files for configuring a software tool for 
formatting the card reader; a selection function for 
selecting one of the prestored card reader configuration 
files based upon card reader type; a dynamic memory for 

35 storing the card reader configuration file selected 
based upon card reader type, wherein the software tool 
is configured based upon the stored card configuration 
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file, the selection function further selects at least 
one command for formatting the card reader, and the 
selected at least one command is stored in memory of the 
card reader; and a processing function for formatting 
5 the card reader based upon the at least one selected and 
stored command. 

These and other objects of the present application 
are still even further fulfilled by providing an 
apparatus for formatting a card and a card reader, 

10 comprising: a first memory for prestoring a plurality of 
card configuration files and a plurality of card reader 
configuration files for configuring a software tool for 
formatting a card and card reader; a selection function 
for selecting one of the prestored card configuration 

15 files and one of the card reader configuration files 
based upon respective card and card reader type; a 
dynamic memory for storing the card and card reader 
configuration files selected based upon the respective 
card and card reader type, wherein the software tool is 

20 configured based upon at least one of the stored card 
and card reader configuration files, the selection 
function further selects at least one command for 
formatting at least one of the card and card reader, and 
the selected at least one command for formatting at 

25 least one of the card and card reader are stored in 
memory of the respective card and card reader; and a 
processing function for formatting at least one of the 
card and card reader based on the respective selected 
and stored command. 

30 These and other objects of the present application 

will become more readily apparent from the detailed 
description given hereinafter. However, it should be 
understood that the detailed description and specific 
examples, while indicating preferred embodiments of the 

35 invention, are given by way of illustration only, since 
various changes and modifications within the spirit and 
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scope of the invention will become apparent to those 
skilled in the art from this detailed description. 
Brief Description of the Drawings 

The present invention will become more fully 
5 understood from the detailed description given 
hereinbelow and the accompanying drawings which are 
given by way of illustration only and thus are not 
limitative of the present invention, wherein like 
elements are represented by like reference numerals 
10 throughout, and wherein: 

Fig. 1 illustrates an overall block diagram of the 
software tool, the smart cards and the card reader; 

Fig. 2 illustrates the components of the card 
reader ; 

15 Fig. 3 illustrates the components of the smart 

card ; 

Fig. 4 illustrates the components of the tool for 
formatting the smart card and card reader; 

Fig. 5 illustrates a flowchart of the setup phase 
20 for configuring the software tool, prior to formatting 
the smart card and card reader; 

Fig. 6a-6c illustrate the operational phase for 
constructing various commands to format the smart card 
and card reader; and 
25 Fig. 7 illustrates an interfacing architecture and 

accessing methodology that incorporates the software 
tool in accordance with an embodiment of the present 
application. 

Detailed D escription of Preferred Embodiments 
30 The disclosed software tool and methodology enable 

interacting with smart cards and smart card readers. 
The tool and methodology can be used in well-defined 
interfacing architectures that are compatible with 
current and developing standards, and also accommodating 
35 to non-standard products. 

Fig. 1 illustrates the main components of the 
present application for configuring a software tool, 
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usable for formatting or otherwise communicating with 
advanced card systems such as smart cards and/or card 
readers to meet user specification. A software tool 300 
allows the user to work with a smart card 200 via a card 
5 reader 100 as shown in Fig. 1 for example, and create 
files, directories, and secret codes to meet a user 
specification. Basically, the software tool 300 allows 
the user to create desired smart card software 
independent of the type of card reader 100 and the smart 

10 card 200. In addition, the software tool 300 allows a 
user to similarly create card reader software for a card 
reader 100 shown in Fig. 1 for example, independent of 
the type of smart card 200 and card reader 100. 
Further, the software tool 3 00 allows a user to reformat 

15 a smart card reader 100 and a smart card 200 with new 
information. 

Fig. 2 illustrates components of a card reader 100 
for example. The card reader 100 can include a central 
processing unit (CPU) 110 and some type of memory 120. 
20 The memory 12 0 is represented as a single element in 
Fig. 2 for the sake of brevity, but of course can 
include an electrically erasable programmable read only 
memory portion (EE PROM) and a random access memory (RAM) 
portion. 

25 Many smart card readers 100 connect to the software 

tool 300 via a RS 2 32 serial port. The readers may be 
pass-through readers that simply passes communications 
between the software tool 300 and the card 200. The 
communication setting for the pass-through reader 100 

30 should be the same as the card 200 protocol. For 
example, a T = 0 transmission protocol card expects 8 
data bits, even parity and 2 stop bits. Other readers 
100 contain firmware that communicates with the software 
tool wins the reader protocol and translates the message 

35 to the card's protocol. Here, the software tool 300 
port is configured to match the reader's protocol. The 
preferred embodiment of this invention automatically 



BNSDOCID: <WO„._9825239Al_L> 



WO 98/25239 PCT/US97/22429 

8 

configures itself to match the desired protocol. That 
is, for a pass-through reader, the software tool 3 00 is 
configured to match the expected card protocol. 
However, for other port readers, the reader protocol is 
5 matched . 

Fig. 3 illustrates the basic components of the 
smart card 200. A smart card, for example, is a card 
with at least a CPU 210 and memory 220 as shown in 
Fig. 3. The memory 220 can include an EE PROM portion 
10 and a RAM portion similar to that of the card reader 100 
shown in Fig. 2 for example. If the card is a chip card 
that can store data but have little or no processing or 
internal file allocation capabilities, then data is 
addressed directly. If the card is based on an internal 
15 CPU 210, then processing functions may include directory 
and file support, multilevel security management and 
built-in cryptography for encrypting and decrypting 
secured data. Most cards currently produced have a CPU 
210, and are more sophisticated than cards that only 
20 store data. 

The card methodology of the present invention can 
be used for a vast array of cards and card readers. For 
example, the cards can include magnetic stripe cards, 
memory chip cards, COS chip cards with programmable 
25 operating systems, etc. Further, the card readers can 
include a variety of readers for reading such cards. 

Fig. 4 illustrates the components of the software 
tool 300. The software tool 300, in a preferred 
embodiment, is built upon a standard computer work 
30 station. The card methodology is preferably built 
around a Microsoft Windows library of routines that 
provide support for interfacing smart cards 2 00 and card 
readers 100, wherein the software tool can communicate 
with and can be used to format smart cards 200 and card 
35 readers 100, either singly or in combination. In one 
preferred embodiment, the Microsoft Window library of 
routines is in the form of a component for the Delphi 
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Programming Environment . The software tool 3 00 creates 
a unique methodology for formatting all types of smart 
cards 200 and card readers 100 to create interf aceable 
smart cards 200 and card readers 100 based upon user 
specification through the creation of a series of 
configuration files. 

The basic components of the software tool 3 00 
include those of a basic computer workstation. A 
central processing unit 310 is used to control various 
components including a display 340, a memory 320, an 
input device 350, and a dynamic memory 330. The memory 
320 stores a variety of configuration files including 
CDC (card) files and RDC (card reader) files for a 
plurality of card and card reader types. Based upon a 
particular type of smart card or card reader, a card or 
card reader configuration file is selected by input 
device 350 and stored in dynamic memory 330. The 
software engine of the software tool, being an open 
engine, is then configured based upon the selected 
configuration file to permit easy communication with the 
particular type of card or card reader. Then, based 
upon desired commands for formatting or otherwise 
communicating with a smart card 200 or a card reader 
100, various commands are selected through input device 
350. These selected commands are then formatted and can 
then be stored in memory 220 and/or 120 to thereby 
communicate or format a desired smart card 200 and/or 
card reader 100 based upon user specification. 

Configuration files, including both CDC and RDC 
files, can further be displayed to a user on a display 
340, as can a list for formatting or otherwise 
communicating with a card or card reader. It should be 
noted that the dynamic memory 330 is merely 
representative in Fig. 4 and can include both random 
access memory and read only memory, as can memory 320 of 
Fig. 4. Basically, the memory 320 designates a memory 
for prestoring a plurality of files for configuring the 
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"open" engine of the software tool for use with various 
types of card readers and smart cards, and dynamic 
memory 33 0 designates a memory for storing a selected 
reader and/or smart card configuration file selected 
5 based upon card and/or card reader type, wherein an 
input device 350 is used to select card and/or card 
reader configuration files and to select various 
commands for formatting or otherwise communicating with 
a card and/or card reader. Operation of the EZ card 
10 formatting system and method will be explained as 
follows. 

Operation of the system and method for creating 
easily interfaceable smart cards, card readers and 
information systems, to create or format a smart card 
15 and card reader and in essence configure a variable 
software engine which communicates with the information 
system, reader and card, occurs in two phases, a setup 
phase and an operational phase. In order to configure 
a software engine of a software tool, for formatting 
smart card and card reader based on user specification, 
configuration files are prestored for configuring the 
software engine based upon various types of smart cards 
and card readers; a configuration file is selected and 
stored based upon a type of card or card reader to be 
25 formatted; the software tool is configured based upon 
the selected and stored configuration file; desired 
commands for formatting or otherwise communicating with 
the card or reader are selected based upon user 
specification; and a card and/or card reader are 
30 formatted based on the selected card and/or card reader 
commands. 

For every different card or card reader, there is 
the normally unique set of commands, wherein each 
command includes an associated instruction. Instead of 
35 having to hardcode desired instructions within a 
software engine, all the commands and instructions are 
stored in configuration files, including smart card 



20 
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(CDC) configuration files and card reader (RDC) 
configuration files for various types of cards and card 
readers. Thus, if a new command is to be introduced, 
instead of having to rewrite the entire software engine, 
5 the system can add a new command and associated 
instruction configuration files so that a software 
engine can read in the information and reconfigure 
itself to work with the appropriate reader and/or card* 
The basics of the setup phase are as follows. 

10 As shown in Fig. 5, the setup phase begins at Step 

S2 . At Step S4 , if desired, a reader RDC 

(configuration) file is selected using input device 350. 
A list of RDC files for various types of readers can be 
displayed on display 340 for example. Once selected 

15 based upon a type of reader in Step S4 , the selected 
configuration file is then read into dynamic memory 330 
and stored therein in step S6. 

Thereafter, card configuration files are displayed 
for various types of smart cards. A card configuration 

20 file (CDC) for a particular type of smart card to be 
configured is selected in Step S8. The CDC file of the 
selected smart card type is then read into dynamic 
memory in Step S10 and the set up phase for setting up 
a card and card reader ends in Step S12 of Fig. 5. The 

25 open software engine of the software tool 300 is then 
configured based upon the selected RDC or CDC file to 
thereby initialize the engine for communication with the 
selected reader or card. 

Accordingly, in the setup phase, the Microsoft 

30 Windows library of routines that provide support for 
interfacing smart cards and readers is populated with 
information (from a configuration file) specific to a 
type of smart card or smart card reader to be formatted, 
namely the library is populated with products specific 

35 information. Thus, information specific to a type of 
smart card and card reader are selected and retrieved 
from the CDC and RDC configuration files for all types 
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of smart card and card reader products stored in memory 
320 (or an external memory) . The selected and stored 
configuration file contains operational parameters 
(product information, transmission protocol, error 
5 handling, command/response processing) as well as 
details of each supported command. Further data of 
configuration files includes transmission/reception 
elements, communication protocol, potential error codes 
and messages, position in response to strings of key 

10 information, and parameters (instruction, unique errors, 
response information, etc) for a re-supported command. 
A typical reader that can process five commands and a 
card that has 2 0 available commands, would result in 
approximately 300 values being read from the RDC and CDC 

15 configuration files. Reference is made to the CDC and 
RDC configuration file specification section described 
hereafter, for guidelines. In short, a configuration 
file lists in text format, all the data necessary for 
the component to communicate and operate with the 

20 product. Thus, based upon the selected and stored CDC 
or RDC configuration file, the engine of the software 
tool can be configured for formatting or otherwise 
communicating with a card or card reader. 

At the beginning of the setup phase in Step S2 , the 

2 5 Delphi component as the open software engine is added to 

the application (the configuration of a system for 
formatting or communicating with a type of smart card 
and card reader based on user specification) that is 
being developed. Next, RDC and CDC files are selected 

3 0 that match the products (type of card and reader) to be 

used by the application in Steps S4 and S8. After 
retrieving the information from the appropriate RDC and 
CDC files, and storing these selected configuration 
files in dynamic memory 330 in Steps S6 and S10, the 
3 5 engine of the software tool is configured and is ready 
to control product operation. 
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The operational phase begins at Step S2 0 as shown 
in Fig. 6a. This is the phase where a user can select 
from the plurality of prestored configuration files for 
a card or card reader, and can configure or reconfigure 
5 the software engine to desired specifications. During 
the operational phase, commands are assembled and 
executed in real time. Further, all Microsoft Windows 
messaging, including external port activation, response 
routing and error handling, are easily processed. 

10 In the setup phase, one of a plurality of prestored 

reader configuration and card configuration files are 
selected based upon a type of reader and/or card to be 
formatted or otherwise communicated with, wherein the 
selected file is stored in dynamic memory 33 0 of the 

15 software tool 3 00. During the operational phase 
process, at least one desired card and/or reader command 
is selected. The at least one selected card and/or 
reader command is then formatted and stored in memory of 
the respective card and/or card reader, namely in memory 

2 0 2 20 and/or 120 as shown in Figs. 3 and 2, respectively. 
The card and/ or card reader can then be formatted or 
reprogrammed based upon the files stored in memory 
therein. 

More specifically, once the operational phase 

2 5 begins in Step S2 0, the system proceeds to Step S22 

wherein a command string is constructed. A command 
string denotes user specification of a CDC or RDC file. 
A single command line can be used within an application 
code to instruct the component to process and send the 

3 0 command, as well as handle any response information. 

The component accepts an English-like command with 
associated parameters and converts it into an 
instruction having a series of numeric valves, for 
example, hex values for transmission to the reader. For 
35 example, in Step S22, the command string: 

TSmTool ♦ ExecuteCommand ( [cmdname, parameter list] ) ; 
wherein "cmdname" is the command to be executed and 
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"parameter list" is the comma separated information 
required to correctly process the command. The process 
then proceeds to Step S24 of Fig. 6a. 

In Step S24 of Fig. 6a, the constructed command 
5 string is compared to commands from the rdc file 
selected during the setup phase based upon the type of 
reader to be formatted, and stored in dynamic memory 
33 0. In Step S2 6, it is thereafter determined whether 
or not the constructed command string, which is used to 
select at least one of the card reader files, matches 
the commands of the RDC file selected during the setup 
phase and stored in dynamic memory 330. If not, then in 
Step S28, the command string constructed in Step S22 is 
compared to commands from the CDC file selected during 
15 the setup phase. The configuration file is selected 
based upon the type of card to be formatted and is also 
stored in dynamic memory 330. In Step S30, it is 
determined whether or not the constructed command string 
matches the commands of the CDC file stored in dynamic 
memory 3 30 based upon the type of card to be formatted 
to determine whether or not the constructed command 
string is being used to select at least one card 
command. If not, then in Step S32, the command is not 
recognized and in Step S34, the process is returned to 
25 await a new command string. 

If the command string of Step S22 does match either 
a command in a stored RDC file in Step S2 6 or a command 
in a stored CDC file in Step S30, then the command can 
be formatted in Step S36 of Fig. 6a. More specifically, 
30 tag command information that correspond to the match 
found in Step S26 or Step S3 0 is determined such as 
instruction information, unique error information, 
response time/length information, etc. Then, every 
character of the instruction tag is looped through. 
3 5 Place holders are substituted with actual values from 
the parameter list. Those place holder names that begin 
with the letter "X" are entered as literal hex values, 



20 
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and those numbers that begin with "Z" are translated to 
ASCII equivalents. Thereafter, other command formatting 
procedures are stepped through as determined by- 
appropriate sections in the reader and/or card 
5 configuration file. Preface information is then added 
to the command including: reader/card NAD and length 
byte(s). If appropriate, an EOT byte is added. 

Thereafter, reader additions for card IN/OUT types 
commands, as determined by the stored configuration 

10 file, are added. If required, transport layer protocol 
(TLP) is added as required. TLP converts each byte into 
two ASCII characters to prevent equipment from 
interpreting, any control characters. Finally, an 
appropriate epilogue is calculated-error byte(s). This 

15 is typically the bitwise XOR calculation as defined by 
EDC type parameters in the reader RDC configuration 
file. This error byte is often added to the end of the 
command string and used for transmission verification* 
The transmitting and receiving of the command will now 

2 0 be described as follows with regard to Fig. 6b. 

Once a command has been formatted in Step S3 6, the 
formatted command is then transmitted to the reader (or 
card) in Step S38. A wait stage is entered in Step S40. 
In Step S42, the communication port buffer of the 

25 software tool (workstation) 300 is continuously polled 
for a response from the reader (or card). In Step S44, 
it is determined whether or not a predetermined response 
time has lapsed without feedback from the reader (or 
card) . If the response time has lapsed, error checking 

30 for time-out occurs and the system proceeds back to Step 
S38. If the time has not lapsed and a response has been 
received, then in Step S46 a response from the reader 
(or card) is extracted from the communication port 
buffer. Data is then preprocessed (EX. reverse TLP if 

35 appropriate) to get ready for the response analysis. 
Any communication port errors are deciphered and the 
process proceeds to Fig. 6c. 
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In Fig. 6c f the process for handling the response 
is described. Initially, in Step S48, the response is 
checked. Specifically, post NAD and EDC are verified to 
determine that they are correct. An incorrect match 
5 could indicate a transmission problem. If a problem 
occurs, an attempt is made to request that the reader 
resend the response. 

In Step S50, the system looks for a reader return 
code (RC) . The location of this byte(s) is defined by 

10 the reader configuration file (RDC) . If an error 
occurs, then the RC is matched with common reader 
errors. If no match occurs, and the command is a reader 
level command, then the process continues to check for 
unique errors. The reader RC is located, or not, in 

15 Step S52. 

If the reader RC is not located in Step S52, then 
the system moves to look for a card command and then 
continues to evaluate a response for card processing 
information. Specifically, a card RC (return code) is 

20 looked for in Step S54. If the card RC is not okay, 
then it is compared against common card errors and 
errors that might be unique to the command that has been 
issued. The card RC is located, or not, in Step S56. 

If a card RC is located in Step S56, then the 

25 system moves to Step S58 wherein response data is 
obtained. If a card command has been issued, then 
response data must be obtained. For example, if the 
card command that had been issued was to read the first 
file in the card, then the response data segment would 

30 be the contents of file one. This also requires that 
the response be converted ASCII. 

Thereafter, if a reader RC or card RC was located, 
the command is processed in Step S60. The commands are 
stored in the appropriate memory 120 or 220 of the card 

35 reader 100 or smart card 200 and are used to format the 
card reader or smart card. Of one final note is that 
during the processing step in Step S60, the properties 
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RtnData, RtnCode, RtnStatus, RtnSent are populated with 
the status information to allow the application to check 
if a command was processed, and how it was processed. 
Thereby, the reader or card are formatted. 
5 During the operational phase, a single command line 

can be used within an application code to instruct the 
component to process and send a command, as well as 
handle any response information. The component accepts 
an English-like command with associate parameters and 

10 converts it to a series of hex values for transmission 
to a reader. The following example is as follows: 

Using the component, namely software tool 300, a 
software developer could write the following line to 
verify if the first secret code stored on a smart code 

15 is in fact the word "test code": ExecuteCommand 
[ (CrdPresentCode, "1" , "test code") ] . 

If the aforementioned instruction was intended for 
one particular card being read by a specific reader, the 
component would automatically translate the command and 

20 send a series of hex bytes to the card reader through a 
communications port of the software tool 300 as follows: 
[65 0D 00 20 00 01 08 74 65 73 74 63 6F 64 65 5B] . The 
component translates the response [56 04 00 2 0 98 04 EE] 
to mean "incorrect secret code", which is then returned 

25 to the application of the developer. 

Now, assuming that during the setup phase, an RDC 
configuration file and a CDC configuration file were 
instead loaded for another reader and card, 
respectively. To perform the same function, the series 

30 of bytes sent to the reader would be, for example: [36 
30 30 45 31 34 30 30 34 32 30 30 30 31 30 38 37 34 36 35 
37 33 37 34 36 33 36 46 36 34 36 35 32 41 03]. The 
response bytes received from the reader would then 
prompt the component to reapply with the "incorrect 

35 secret code" status. 

It should be noted that this software code remains 
exactly the same and an identical response is generated 
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even though a different reader and card are used. The 
software developer does not need to be concerned with 
the complexities of how these commands are assembled. 

From an application user perspective, it should be 
5 noted that how a product that is built on the card 
methodology, for example, an EZ card methodology, would 
appear to an end user is dependent on the type of 
application. Frequently, applications built on EZ card 
methodology will perform dedicated tasks. For example, 

10 a front desk module in a hotel system would be limited 
to issuing new cards to arriving guests. it should be 
noted, that although smart cards are discussed in 
connection with the present application, other cards 
such as magnetic stripe cards, memory chip cards, and 

15 COS cards can also be used. 

Some features are common to all applications of the 
EZ card methodology. Specifically, applications would 
require the following steps at a minimum: a reader 
would have to be connected to a host software tool 300 

20 through a communications port; MS windows would have to 
be started; a program would have to be run; a 
configuration (set up) option to select which CDC and 
RDC files match the type of card and reader being used 
would have to take place; the reader would have to be 

25 powered on; the card would have to be powered on; and 
one or more of the reader and card functions or commands 
would have to be performed to format the card and 
reader. Examples include: create file/directory 
structures, read files, update files, authenticate 

30 codes, review file status, implement security 
schemes/access conditions, etc. 

Regarding the formatter operation, the software 
tool includes a formatter, herein referred to as an EZ 
formatter, that is a typical utility program built on 

35 the EZ card methodology. It provides an easy way to 
interact with readers and cards. The EZ formatter can 
be used: 1) to format blank cards; 2) to personalize 
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cards; 3) in training; 4) in front end to demo systems; 
5) to verify card authenticity; and 6) to test card 
security schemes, for example* A tool status bar at the 
top of the screen provides global function (example 
5 reset card and reader) and status information (example 
active directory/ file) . The application has five screen 
pages that can be selected via notebook tabs. Each page 
represents a different grouping of functions, 

A first type of page is a configuration page. This 

10 page is used to set RDC and CDC reader and card 
configuration files to be used (based upon card/card 
reader type) . It also selects the type of communication 
between the reader and host work station (such as a 
serial port number, parallel port, PCMCIA , etc.)- A 

15 second type of page is a security page. All secret 
codes are created and verified here. Codes can also be 
changed or unblocked as appropriate. Directory/file 
status and access conditions can be reviewed. 

Template pages are a third type of page which 

20 define and create directory/ file structures on smart 
cards. Structures can be saved to disk and retrieved 
for the future. When creating a new file or directory, 
the user is prompted for a file type, length, address, 
and access conditions. Files can also be deleted. A 

25 card viewer page is another type of page wherein the 
card viewer page is used to write and to read from 
selected files. The card viewer page can be used to 
dump the contents of an entire card. Finally, a 
writable area page can be used, however this page is 

30 relevant only from memory cards. The page shows a 
visual map of the card-to-memory addresses including 
which cards have been written and which cards are still 
unused. 

CDC and RDC Configuration File Specifications 

35 This section describes the structure and allowable 

formats for configuration files (referred to as CDC and 
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RDC files) that are compatible with the preferred 
embodiments of the invention. 

The CDC an RDC files are formatted similar to MS 
Windows in files. A unique CDC and RDC file is required 
5 for every card and reader type that is to be used. 
File Structure 

The general format follows the Windows in 
structure. Section headings are in brackets. Under 
each section parameter, names are listed (one per line) 
10 followed immediately by an equals sign and the 
associated data value. For example: 

♦ [Section Heading] 

• Parameter l=Valuel 

* Parameter2=Value2 



♦ [Section2 Heading] 
ParameterX=ValueX 

20 • .... 

All CDC and RDC files contain the following required six 
sections: 

♦ AUTHOR 

♦ PRODUCT 

25 • COMMUNICATION PROTOCOL 

♦ TRANSMISSION 

♦ RECEIVE 
COMMANDS 

Additional sections may then follow, such as one 
3 0 for each command listed in the COMMANDS section. For 
example, a reader type RDC file that defines two 
commands (readeron, readeroff) in the COMMANDS section 
will have two additional sections [READERON] and 
[READEROFF] that list the respective functional 
35 information. 

Parameter names and values must be located under 
the correct Section heading. Not all CDC and RDC files 
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will have the same parameter names. Differences between 
reader and cards are represented by variations within 
the CDC and RDC files. To be understood correctly by 
the EZ Card System, data values must conform to the 
5 defined standards (See Contents and Descriptions) . 
Contents and Descriptions 

Product Type defines the parameters as valid for a 
reader , card, or both. 

Allowable Values are typically one of the following: 
10 (1) Integer: Positive whole numbers (up to 4 

digits) 

(2) String: Collection of characters not to 
exceed length of 255 

(3) Specific: Exact entries are shown in italics 
15 (4) Hex: Two digit hex values. When there is 

more than one, the members of the series should be 
separated by a single space. For example: RC 
Success=90 00 

(5) ErrFormat: hex, comma, space, error 

2 0 description. For example: 

Common Errorl=92 00, Write Problem in EEPROM 
Common Error2=98 04, Required secret code not 

presented. 

Description explains how the values are interpreted by 
25 EZ Card System. 

Author: This section identifies the source and/or 
author of the CDC and RDC file. 
Creation Date 

Product Type: All 
30 Allowable Values: string 

Description: Date of CDC and/or RDC file. 
Company 

Product Type: All 

Allowable Values: string 

3 5 Description: Name of company which created CDC 

and/or RDC file. 
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Individual 

Product Type: All 
Allowable Values: string 

Description: Name of individual which created CDC 
5 and/or RDC file. 

Comment 

Product Type: All 
Allowable Values: string 

Description: Additional information (ex. 

10 Phone/ email of individual) 

Product This section identifies the product to which 

the CDC and/or RDC file pertains. 

Name 

Product Type: All 
15 . Allowable Values: string 

Description: Brand name of product 
Manufacturer 

Product type: Both 

Allowable Values: string 
20 • Description: Name of Manufacturer of product 

for which the CDC and/or RDC files have been 

configured. 

Type 

Product Type: Both 
25 . Allowable Values: 1, 2, 3 

Description: Identifies the CDC and/or RDC 
file as that for a: 
reader - 1 
smart card - 2 or 
30 PCMCIA card - 3 (future) 

Communication Protocol: This section contains parameter 
information needed to initiate a communication link to 
the host. A Serial RS232 port interface can be used for 
readers. Alternatives include PCMCIAN, parallel, and 
35 keyboard port interfaces. 
R ad r Type 

Product Type: Reader Only 
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Databits 



15 



Stopbits 



20 
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Allowable Values: PCMCIA, SERIAL, PASSTHRU 
Description: Define the reader to be used. 

Product Type: Reader Only 

Allowable Values: 9600, 14400, 19200, 38400 
Description: Defines the speed at which the 
reader will operate. 

Product Type: Reader Only 

Allowable Values: even, odd, none, mark, 
space 

Description: Defines the parity bit for 
reader communication. 

Product Type: Reader Only 
Allowable Values: 7, 8 

Description: Defines the data bit for reader 
communication . 



Product Type: Reader Only 
Allowable Values: 0, 1, 2 
Description: Define the 
reader communication. 



stop bit(s) for 



Card Type 



25 



30 



35 



Product Type: Smart Card Only 
Allowable Values: COS, MEM, MAG 
Description: Identifies the card as a: 
Chip Card with Card Operating System - COS 
Memory card - MEM 
Magnetic stripe card - MAG 
Memory Area 

Product Type: Smart Card Only 

Allowable Values: SFN, CAF, parameterized 

range, or integer 

Description 

1. For MEM cards, the writable area is given 
as a parameterized range. Start address 
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and length of area, repeat as necessary 
with pairs separated by commas. For 
example: a memory card that has two 
writable areas... the first from byte 1 
5 to byte 50, the second from byte 75 to 

100 would be as follows: Memory Area=l 
49, 75 24 

2. For MAG cards this integer value will 
list how many tracks the card supports. 
10 3 . For COS cards this identifies how new 

files are created 

System assigns File Names - SFN or 
Card Allocates Files -CAF 
Transmission This section defines how command strings 
15 are constructed and transmitted to the reader/card. 
Information includes command composition, address 
identifiers, and error detection techniques. 
Reader NAD 

Product Type: Reader Only 
20 . Allowable Values: Hex 

Description: Node address of the reader 

Card NAD 

Product Type: Reader Only 
Allowable Values: Hex 
25 . Description: Node address of the card. Used 

to direct commands through the reader to the 
card. 

EDC Type 

Product Type: Reader Only 
30 . Allowable Values: 1, 2, 3, 4 

Description: identifies how much of command 
string should be XOR in order to arrive at 
correct error byte: 

entire string - 1 
3 5 ignores NAD - 2 

ignores EOT - 3 
ignore both NAD & EOT - 4 
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Two Pass ACK 

Product Type: Selected Readers 
Allowable value: Hex 

Description: Acknowledgement hex value 

5 returned by those readers that send ACK prior 

to processing command (2 pass protocol) . 

EOT Flag 

Product Type: Selected Readers 
Allowable value: Hex 
10 . Description: End of Transmission code that is 

added to command string. 
Composition Type 

Product Type: All (currently used for Readers 
only) 

15 . Allowable Values: 0, TLP, TLP1, PCSC 

Description: identifies format which command 
strings : 
Normal - 0 

Transport Layer Protocol. Each byte is 
20 transmitted into two ASCII characters - TLP 

Process data only - TLP1 
Card Command In 

Product Type: Selected Readers 

Allowable Values: Hex 
25 . Description: Code that must preface card 

levels commands that send data to the card. 
Card Command Out 

Product Type: Selected Readers 

Allowable Values: Hex 
30 . Description: Code that must preface card 

level commands that retrieve data from the 

card and send it out to the host. 
Card Command Tl 

Product Type: Selected Reader 
35 * Allowable Values: Hex 

Description: Code that prefaces T=l commands 
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Length Bytes 

Product Type: All 
Allowable Values: 0, 1, 2 

Description: identifies how many bytes are 
5 used for sending length byte. If o then 

product does not require a length byte. 
Receive This section defines the structure of response 

as they are received back to the host. 
Response NAD 
10 . Product Type: Reader Only 

Allowable Values: Hex 

Description: Node address of response (host 
terminal) 
RC Reader Location 
15 . Product Type: Reader Only 

Value: Integer 

Description: Byte number after the NAD where 
the reader return code (RC) begins. For 
example, if the response for reader level 

20 commands is: NAD+LEN+RC+data+EDC , then the RC 

Reader Location would be 2 . 
RC Card Location 

Product Type: Reader Only 
Value: Integer or END 

25 . Description: Byte number after the NAD where 

the card level return code begins. If the RC 
is always at the end of the response then this 
value should be "END". 

RC Success 
30 . Product Type: All 

Allowable Values: Hex - multiple allowable 
success codes are separated by command and a 
space. Example: RC Success=90 00, 60 90 



Description: The return code(s) that indicate 
35 a successful execution of a command. 
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CommonError* where * equals a sequentially increasing 
integer up to number of Errors to be listed. 

Product Type: All 

Allowable Values: ErrFormat 
5 • Description: List of return codes and 

associated error messages. 
Commands This section lists the possible commands. 
Command* where* equals sequentially increasing integers 

up to number of commands to be listed. 
10 . Product Type: All 

Value: String 

Description: These values are the command 
identifier names that will appear as CDC and 
RDC file section headings in the remaining 
15 sections of file. 

Example: 

Commandl=CrdPresentCode 
Command2=CrdReadFile 
Two additional sections [CrdPresentCode] and 
20 [CrdReadFile] must be established to hold the command 
details. 

While the commands can be completely customized by 
the CDC and RDC file author, a suggested convention is 
to include the following commands at a minimum. 
25 For Reader RDC file: RdrReset ,Rdr0f f ,RdrStatus. 

For Card CDC file: CrdPresentCode, CrdCreateFile, 

CrdReadFile , CrdWriteFile , 
CrdStatus. 

[Command Identifier] Each command listed in the 
30 Commands Section will have its own separate section to 
describe the details of the command ( instruction , 
errors, response time/length) 
Type 

Product Type: All 
35 . Allowable Values: 0, 1, 2, 3 

Description: Defines command exchange 
0 - normal exchange of bytes 
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2 



3 



1 



reader command controlled by serial 
line 

single byte at a time 
chained command 



Instruction 



10 



15 



20 



25 



30 



Product Type: All 
Allowable Values: Hex/Special 
Description: Actual sequence of bytes that 
formulate the command. The Instruction is the 
sequence of hexadecimal bytes that is sent to 
the reader/card. In many instances the 
Instruction will contain placeholders for 
additional information that must be added by 
the application for the command to be 
correctly constructed. For example, consider 
the command named "CrdPresentCode. " • The 
Gemplus COS card representation is: 

lnstruction=00 2 0 00 xnum 08 zcode 



where xnum represents the number of the secret code to 
be presented and zcode represents the actual code. 
Placeholders prefaced with the letter "x" pass their 
value as a hex. Placeholders prefaced with the letter 
"z" pass their actual character value. When the above 
instruction is called from an EZ Card System application 
with the additional parameters "1" and "usercode" , the 
component appends the hex representation of bytes to 
read: 

00 20 00 01 08 75 73 65 72 63 6F 64 65 
Response Time 

Product Type: All 
Allowable Values: Integer 

Description: Time in milliseconds that host 
should wait for response. After the elapsed 
time, host will consider that an error has 
occurred and return a time-out. 
Response Length 

Product Type: All 
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Error* 



Comment 



29 

Allowable Values: Integer or Open 
Description: Expected length of response data 
to be received by host. This is in addition 
to the normal return codes and error checks. 
Many commands like writing to a file and 
turning off a reader producing no response 
(i.e. Response Length=0) . Commands lacking a 
predetermined response, for example, reading 
a file, will have a Response Length = Open 
where * equals sequentially increasing 
integers up to number of unique errors for 
this command (max 8) 
Product Type: All 
Allowable Values: ErrFormat 

Description: Possible errors, unique to this 
specific command, that may be encountered 
during execution. Up to eight separate unique 
errors can be stored for each command. 



Product Type: All 
Allowable Values: string 

Description: Store hint regarding 

implementation of the command. Not actively 
used by E2 Card System. 
Figure 7 illustrates an interfacing architecture 
that includes the software tool described above. The 
application Programming Interface (API) 4 00 or accessing 
methodology kernel, includes higher level card 
functions, such as a series of Dynamic Link Libraries 
(DLLs) that may be called from products, software 
applications or solutions developed by outside users. 
This accessing methodology, which calls on any of the 
appended library modules to process commands, includes 
but is not limited to methods to format and write data 
manage card and reader properties, control the 
registration and operation of add-in modules, instruct 
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and transmit commands, and receive and interpret card 
return codes. 

The accessing methodology manages all interfacing 
with readers and cards. This includes constructing the 

5 commands that are to be directed to the card. Commands 
are converted to a data stream of hexadecimal bytes that 
are typically transmitted out the computer's 
communication port, like the RS232, to an attached 
reader and then forwarded on to the card. The card will 

0 then generate a reply and pass these response 
hexadecimal bytes back up to the computer or host. Also 
included in the accessing methodology are the 
interpretation of response codes, MS Windows system 
messaging, and reader/card error and exception handling. 

5 The invention being thus described, it will be 

obvious that the same may be varied in many ways. Such 
variations are not to be regarded as a departure from 
the spirit and scope of the invention, and all such 
modifications as would be obvious to one skilled in the 

0 art are intended to be included within the scope of the 
following claims. 
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What is Claimed is: 

1 1. A method for communicating with a card and a card 

2 reader, comprising the steps of: 

3 prestoring a plurality of files for configuring a 

4 software tool to communicate with the card as a 

5 plurality of card configuration files; 

6 prestoring a plurality of files for configuring the 

7 software tool to communicate with the card reader as a 

8 plurality of reader configuration files; 

9 selecting one of the card configuration files; 

10 selecting one of the reader configuration files; 

11 storing the selected card configuration file and 

12 reader configuration file; and 

13 configuring the software tool for communicating 

14 with the card and card reader based upon the respective 

15 stored selected card and card reader configuration 

16 files. 

1 2. The method of claim 1, further comprising the steps 

2 of: 

3 selecting another one of the card 

4 configuration files; 

5 storing the another card configuration file in 

6 place of the stored card configuration file; and 

7 reconfiguring the software tool for 

8 communicating with another card based upon the stored 

9 another card configuration file. 
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1 3* The method of claim 2, wherein the cards are smart 

2 cards. 



1 4. The method of claim 1, further comprising the steps 

2 of: 

3 selecting another of the reader configuration 

4 files; 

5 storing the another reader configuration file 

6 in place of the stored reader configuration file; and 

7 reconfiguring the software tool for 

8 communicating with another card reader based upon the 

9 stored another reader configuration file. 

1 5. The method of claim 1, wherein the card is a smart 

2 card. 



1 6. The method of claim l, further comprising the steps 

2 of: 

3 selecting at least one first command based 

4 upon the card configuration file; 

5 selecting at least one second command based 

6 upon the reader configuration file; 

7 formatting the card based upon the at least 

8 one first command; and 

9 formatting the card reader based upon the at 
10 least one second command. 

1 7. The method of claim 6, further comprising the steps 

2 of: 

3 formatting and storing the at least one first 

4 command ; and 

5 formatting and storing the at least one second 

6 command. 

1 8. The method of claim 7, wherein the at least one 

2 formatted first command is stored on a card memory and 
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3 the at least one formatted second command is stored on 

4 a card reader memory. 

1 9. A method for communicating with a card system, 

2 comprising the steps of: 

3 prestoring a plurality of files for 

4 configuring a software tool for communicating with the 

5 card system; 

6 selecting one of the prestored files; 

7 storing the selected file; and 

8 configuring the software tool for 

9 communicating with the card system based upon the stored 
10 file. 



1 10. The method of claim 9, wherein the card system 

2 includes at least one of a card and a card reader. 

1 11. The method of claim 9, further comprising the step 

2 of: 

3 selecting at least one command based upon the 

4 stored file; and 

5 formatting the card system based upon the 

6 selected at least one command. 

1 12. The method of claim 11 , further comprising 

2 formatting and storing the at least one command. 

1 13. The method of claim 12, wherein the formatted at 

2 least one command is stored in memory on the card 

3 system. 

1 14 . A software tool for communicating with a card 

2 system, comprising: 

3 first memory means for prestoring a plurality of 

4 card system configuration files for configuring the 

5 software tool for communicating with the card system; 
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6 selection means for selecting one of the prestored 

7 card system configuration files based upon a card system 

8 type ; 

9 second memory means for storing the selected card 

10 system configuration file in a dynamic memory; and 

11 formatting means for configuring the software tool 

12 for communicating with the card system based upon the 

13 stored card system configuration file. 

1 15. The software tool of claim 14, further comprising: 

2 input means for selecting a command for 

3 formatting the card system; 

4 card system memory means for storing the 

5 selected command in the card system; and 

6 processing means for formatting the card 

7 system based upon the selected stored command. 

1 16. The software tool of claim 14, wherein the card 

2 system includes at least one of a card and a card 

3 reader. 

1 17. The software tool of claim 14, further comprising 

2 subsequent selection means for selecting 

3 another of the card system configuration files; 

4 subsequent storage means for storing the 

5 another card system configuration file in place of the 

6 stored card system configuration file; and 

7 reconfiguration means for reconfiguring the 

8 software tool for communicating with another card system 

9 based upon the stored another card system configuration 
10 file. 

1 18. A software tool for formatting a card and a card 

2 reader, comprising: 

3 a first memory for prestoring a plurality of card 

4 configuration files and a plurality of card reader 
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5 configuration files for configuring the software tool to 

6 communicate with the card and the card reader; 

7 selection means for selecting one of the plurality 

8 of prestored card configuration files and card reader 

9 configuration files based upon a respective card and 

10 card reader type; 

11 a dynamic memory for storing the selected card and 

12 card reader configuration files, wherein the software 

13 tool is configured based on at least one of the stored 

14 card and card reader configuration files, the selection 

15 means further selecting a command for formatting at 

16 least one of the card and card reader; 

17 at least one of a card memory and a card reader 

18 memory that stores the selected command in the 

19 respective card and card reader; and 

20 processing means for formatting at least one of the 

21 card and card reader based on the respective selected 

22 and stored command. 



1 19. A software tool for formatting a card system, 

2 comprising: 

3 a first memory that prestores a plurality of card 

4 system configuration files for configuring a software 

5 tool for formatting the card system; 

6 an input device that selects one of the prestored 

7 card system configuration files based upon a card system 

8 type and that selects a command for formatting the card 

9 system ; 

10 a dynamic memory that stores the selected card 

11 system configuration file, wherein the software tool is 

12 configured based upon the stored card system 

13 configuration file; 

14 a card system memory that stores the selected 

15 command in the card system; and 

16 a processing device that formats the card based 

17 upon the selected stored command. 
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1 20 • The software tool of claim 19 wherein the card 

2 system includes at least one of a card and a card 

3 reader . 

1 21. A system for managing a communication with a card 

2 system, comprising: 

3 a software tool that communicates with a card 

4 system, the software tool including 

5 a first memory that prestores a plurality of card 

6 system configuration files for configuring a software 

7 tool for formatting the card system, 

8 an input device that selects one of the prestored 

9 card system configuration files based upon a card system 

10 type and that selects a command for formatting the card 

11 system, 

12 a dynamic memory that stores the selected card 

13 system configuration file, wherein the software tool is 

14 configured based upon the stored card system 

15 configuration file, 

16 a card system memory that stores the selected 

17 command in the card system, and 

18 a processing device that formats the card based 

19 upon the selected stored command; and 

20 an accessing kernel that controls the communication 

21 between the software tool and the card system. 
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